Method and system for caching virus-free file certificates

ABSTRACT

The present invention relates to computer viruses and more particularly to a method and system, for use in a virus-free certificate cache ( 106 ), of caching one or multiple virus-free certificates ( 200 ), each virus-free certificate certifying that a file is virus-free. The method comprises the steps of:  
     receiving ( 601 ) a virus-free certificate request for a file;  
     identifying ( 602 ) the file in a cache table ( 501 ), the cache table ( 501 ) comprising for each identified file ( 502 ) one or a plurality of virus-free certificates ( 509 );  
     selecting in the cache table ( 501 ) one virus-free certificate ( 509 ) for the identified file ( 502 ), using one or a plurality of anti-virus criteria;  
     retrieving ( 602 ) from the cache table ( 501 ) the selected virus-free certificate ( 509 );  
     sending back ( 606 ) in response to the virus-free certificate request the retrieved virus-free certificate.

BACKGROUND OF THE INVENTION

[0001] 1. Technical Field

[0002] The present invention relates to computer virus and moreparticularly to a method and system for caching one or multiplevirus-free certificates, each virus-free certificate certifying that afile is virus-free.

[0003] 2. Prior Art

[0004] Among all computing and networking security issues, the mostimportant cause of concern does not come from intrusions, but from thewidespread proliferation of viruses. Viral infections represent thegreat majority of all security incidents.

[0005] Virus protection for large organizations has become more and morecomplex and difficult because of:

[0006] the combined use of heterogeneous systems and practices,

[0007] the widespread use of distributed or client/server systems, and

[0008] the free exchange of data files via network sharing, e-mail,Internet . . .

[0009] Until recently, viral infections threatened only data residing onstorage media, such as hard drives and floppy disks. However, with theemergence of macro viruses, the threat has spread to applications. Mostorganizations are not aware of this level of penetration and are notorganized to manage and prevent virus attacks. An effective virusprotection software must prevent infections rather than simply treatingthem after they have already occurred. Anti-virus solutions need auniform plan, with a centralized control, automated virus signatureupdates, and support for multiple platforms, protocols, and file types.

[0010] A computer virus is any program created to reproduce itself. Avirus reproduces itself by attaching itself to programs, files, or evento boot sectors of disks. A virus is activated when the infected file ordisk is opened or accessed. Once a virus resides in a memory, it canattach itself to the next file or disk accessed, and so on. A virus maybe designed to do harm. A virus may also have unintended consequences byoverwriting important computer information and by causing costlyinconveniences to users and network managers. There are four generaltypes of computer virus:

[0011] File Viruses (including macro viruses), which are attached tofiles;

[0012] Boot sector Viruses in which the boot sectors or floppy or harddisks are infected;

[0013] Master Boot Record (MBR) Viruses which infect the disk masterboot record; and

[0014] Multi-partite Viruses that are a combination of a file virus anda boot sector virus.

[0015] Viruses need to avoid detection in order to succeed in corruptingtarget computers. Simple viruses, with easily detectable signatures aregiving way to more sophisticated virus types:

[0016] Polymorphic Viruses: they change their signature, or profile,each time they are activated so that a fixed signature filter will missthem.

[0017] Stealth Viruses: they attempt to hide their presence byintercepting interrupt services and by feeding back false information toanti-virus products and end users.

[0018] Encrypted Viruses: they are delivered within an encrypted fileand are undetectable by a simple anti-virus.

[0019] Every improvement in network and communication technologies opensnew avenues through which viruses can infect your system. Most of formerviruses were boot sector viruses, in which the boot sectors of floppy orhard disks were infected.

[0020] As stated earlier, the creation of macro viruses has changed thisenvironment dramatically. A macro virus is a set of instructionscomprising powerful macro routines initially designed for wordprocessing and spreadsheet applications. These macro languages enable amyriad of useful functions which can be imbedded into a document andwhich can be executed when the document is opened for view or use.

[0021] With the exploding development of the Internet, viruses havecatastrophic possibilities. The Internet introduces two different virusthreats.

[0022] The first threat is caused by the download of files comprisingviruses when these files are browsed or transferred using for instanceFTP (File Transfer Protocol) routines. Public shareware (sharedsoftware) and executable routines of all types, including formattedpresentations, are a growing source of virus infection. Furthermore, newInternet virus threats are beginning to appear in the form of maliciousJAVA and Active-X applets.

[0023] The second threat comes from electronic mail (e-mail). MostInternet e-mail systems provide a very rich capability to attachformatted documents to mail sent over the network. These e-mail messagescan be broadcast to individuals or groups of individuals with the simplestroke of a key! Infected documents or files can flood a corporatenetwork through gateways and mail servers. As networking,telecommunications, remote access, message systems, supportingattachments of all kinds become more and more common, viruses willexploit these new electronic pathways to attack systems that wereheretofore unreachable.

[0024] A third trend in networking also exacerbates the virus threat:the trend towards the deployment of Groupware applications such as LotusNotes, Microsoft Exchange, Novell Groupwise and the like.

[0025] Since the active and repeated sharing of documents over thenetwork is at the core of these applications, they represent a fertileground for the development of macro viruses. A Groupware application notonly acts as a repository for shared documents, but, due to itscollaborative function, it simultaneously broadcasts files to associatedwork groups. The broadcast of files significantly multiplies thepossibility of accidentally deploying mail infected by attached macroviruses and makes Groupware protection a high priority.

[0026] Most viruses attempt to remain undetected as long as possible toextend their destructive influence. Therefore, most viruses do notproduce any recognizable profile or signature that would allow to trapthem by scanning the software. However, viruses perform actions that donot look like normal computer operations or user operations. Theseabnormal actions can be detected by intelligent anti-virus software.Fortunately, many viruses have telltale symptoms and may inadvertentlygive off signals that can alert users and virus protection software totheir presence.

[0027] Some of these symptoms include:

[0028] Increase in byte length of files,

[0029] Alterations of a file's time stamp,

[0030] Delayed program loading or activation,

[0031] Reduced performance,

[0032] Lower system resources, available memory, disk space,

[0033] Bad sectors on floppies and hard drives,

[0034] Strange or non-standard error messages,

[0035] Non-standard screen activity, display fluctuations,

[0036] Program inoperability (failing to execute),

[0037] Incomplete or failed system boots, and

[0038] Uninitiated drive writes.

[0039] Viruses are becoming increasingly sophisticated and, as such, candefeat simpler, single dimension software packages. To be effective, theanti-virus software must include special-purpose, distributedapplications. Applications can detect viruses using five distinctmethods:

[0040] Signature Scanning: This method compares the content of filesagainst a database of virus signatures. This method requires frequentupdates of the database to ensure the identification of new and changingsignatures.

[0041] Integrity Checking: This method compares the profile of currentfiles and disks areas against an archived snap shop of these same items.The detected differences may indicate the presence of a virus. Checksumming is the most common type of integrity checking. Unfortunately,integrity checking is generally not effective against modem stealthviruses, so further detecting means are needed.

[0042] Heuristic Analysis: An artificial intelligence monitorsvirus-like behavior, such as trapping certain interrupt services orattempting unlikely actions such as reformatting the hard disk.

[0043] Polymorphic Analysis: Polymorphic viruses are difficult to detectbecause they constantly change their look, particularly when theyencrypted or when they use stealth techniques to hide their presence. Apolymorphic analyzer will move any suspect file to a separate,protected, location in the computer and will execute it there to see ifit exhibits any virus-like behavior.

[0044] Macro Virus Analysis: A specifically designed anti-virus softwaredetects macro is in files and tests them before execution.

[0045] In addition to the support of these five types of virus analysis,an effective anti-virus system must also be able to scan archived andcompressed files. Zip (or Pkzip) and Microsoft Compression are the mostcommon tools for archiving and compressing a file. A virus can hideinside a compressed archive, and can remain dormant or unnoticed untilthe infected file is extracted and released into a system. The minimumfor an efficient anti-virus system is to be able to scan most currenttypes of archives to identify viruses stored within the files theycontain.

[0046] Finally, the ability of a virus software to prevent virus attacksis determined by its ability to maintain an updated virus signaturedatabase. Any anti-virus software must have an associated, easilyaccessible Web site, or some other online source of information, whereregular virus database updates can be retrieved. Products that automatethis update process by using an Internet connection to regularly collectnew information have a clear advantage in this regard.

[0047] Most anti-virus software can perform a scan of a computer inorder to detect and possibly treat the viruses found at that time. Thisprocess is called scanning. Scanning a computer for viruses can occur:

[0048] at regular intervals under the control of a schedule, or

[0049] as an on-demand operation manually executed, or

[0050] as an event-activated operation (usually in response to somerecognizably “illegal” behavior by a potential virus).

[0051] In addition, viruses can be detected in real time, when they arereceived. This capability is important because if viruses can bedetected when they attempt to enter within a system (computer, datarepository, server . . . ), then it is possible to prevent them fromcorrupting other files. Oftentimes, a scheduled scan may occur after avirus has already entered within a computer and has corrupted otherfiles. Obviously, the earlier a virus can be detected, the better.

[0052] To be truly useful, an anti-virus software must have the abilityto perform all types of scans.

[0053] A Certificate is a structure that contains a public value (i.e. apublic key) associated with an identity. For instance, within a X.509Certificate, the public key is bound to a “user's name”. A third party(a Certificate Authority) attests that the public key belongs to theuser. A X.509 Certificate is a very formal structure and comprisesdifferent elements:

[0054] Subject: This is the “user's name” (the Subject can be anyidentity value).

[0055] Issuer: This is the name of the third party that hasissued/generated the certificate. This third party is the CertificateAuthority (CA).

[0056] Public Key Value: This is the public key of a public/private keypair. An associated field defines the public key algorithm that must beused, for instance a RSA, Diffie-Hellman or DSA public key.

[0057] Validity: Two fields are used to define the period of validity(valid from date 1 and valid to date 2).

[0058] Serial Number: This field provides a unique Certificate serialnumber for the issuer.

[0059] Signature: The signature is an encrypted digest generated by theCertificate Authority (CA) for authenticating the whole certificate. Thedigest results from the hashing of the Certificate. The digest isencrypted using the CA private key. The encrypted digest which is thesignature, “certifies” that the Subject is the “owner” of the public andprivate keys.

[0060] The Certificate needs to be verified to ensure that it is valid.This is a quite complex process. The verification by an end user of aCertificate comprises the checking of the following elements:

[0061] Valid (or any) Subject and Issuer names are defined in theCertificate.

[0062] The Certificate is not expired (checking of the Validity periodfield).

[0063] The Certificate has not been revoked (this may be determined byobtaining a current Certificate Revocation List from the CA).

[0064] The signature on the Certificate is valid (the signature is notverified by using the Certificate's public key but by using the CApublic key).

[0065] The method for validating the signature is quite simple, andcomprises the steps of:

[0066] extracting the issuer's name (CA name) from the Certificate;

[0067] locating the issuer's Certificate (CA Certificate) or theissuer's public key (CA public key)

[0068] checking that the end user's Certificate signature was generatedby the issuer (CA) using the issuer's public key (CA public key).

[0069] Certificates are generated by a Certificate Authority (CA). Twomain methods can be used:

[0070] Centralized Generation: The private/public key pair is generatedby the end user (defined in the subject field of the Certificate). Thepublic key is directly provided by the end user to the CA software tocreate a Certificate. The Certificate can be provided to another enduser via any suitable channel. The channel does not have to be securebecause a Certificate is a self protecting structure (given the CA'ssignature).

[0071] Distributed Generation: The private/public key pair is generatedby the end user. The end user requests the CA to build a Certificateincluding the end user public key. The public key is then sent to the CAfor certification. If the request is valid then the CA returns aCertificate associating the user identity with the user public key tothe end user.

[0072] Of course these two methods can be combined in any system,because trusted CA keys are generated by the Certificate Authority (CA).

[0073] Current anti-virus method are becoming more and more complex dueto:

[0074] the number of viruses,

[0075] the difficulty to fine them, and

[0076] the fact that their signature can change with time orenvironment.

[0077] the fact that their signature can change with time orenvironment.

[0078] Viruses are coming from everywhere and especially from theInternet network. The time required to check a disk within a computersystem, becomes more and more important. Furthermore, the checking of adisk involves the use of resources which may prevent the normal use ofthe computer system.

[0079] It is an object of the present invention to improve currentanti-virus checking methods and to provide a new method using fileCertificates similar to X.509 Certificates used to authenticate anidentity. A specific process associates a Certificate, called virus-freeCertificate (VC), with a file in order to speed up and improve the virusdetection.

[0080] It is another object of the present invention to reduce theconsumption of resources (for instance, the CPU-Central Processing Unit)and to reduce the time necessary to detect viruses within files. Thisreduction is especially important on systems handling a huge amount oftraffic (for instance IP Routers or Firewalls). The performance of suchsystems is highly impacted by usual anti-virus checkers because usualcheckers require to process each file. The detection of viruses on saidsystems is a very complex process and must be done as fast as possible.

[0081] It is another object of the invention, when a system requires avirus-free Certificate for a particular file, to retrieve thisvirus-Free Certificate as fast as possible, for obvious performancereasons. Copies of existing virus-free Certificates are stored insteadof being rebuilt each time they are required. Retrieving an existingVirus-free Certificate is more efficient (saves time and provides betterperformances) than rebuilding a new virus-free Certificate. Within anetwork, multiple authorities can be used to build a virus freeCertificate for a particular file. They can share, for instance, theload of building virus-free Certificates and can use differentanti-virus checkers. An authority among these multiple authorities mustbe identified when a virus-free Certificate has to be retrieved.

SUMMARY OF THE INVENTION

[0082] The present invention relates to computer viruses and discloses amethod and system for caching anti-virus certificates. Each anti-virusCertificate associated with a file comprises a file signature. The filesignature is generated by a trusted server (a Virus-free CertificateAuthority-VCA) which avoids the system which receives the file to checkthis file for all existing viruses. The Virus-free Certificate Authorityvalidates the file against all known viruses, using one or severalanti-virus checkers. In case of new viruses, only the virus-freeCertificate is changed and the only process performed by the systemreceiving the file (typically a network device) is to verify the fileagainst the file signature included in the virus-free Certificate, andto filter the file according to predetermined rules. The presentinvention drastically simplifies the computing resources used fordetecting viruses on network devices such as IP Routers and Firewalls.Files on Web Servers can be downloaded with their anti-virusCertificates suppressing the risk of virus. The full anti-virus isprocessed once on the Virus-free Certificate Authority instead of beingprocessed on each system. Since the processing resources required on thesystem are limited (because the anti-virus checker is processed on theVirus-free Certificate Authority and not on the network device), theperformance impact on the system is also limited.

[0083] The method and system of caching one or multiple virus-freecertificates, each virus-free certificate certifying that a file isvirus-free, comprises the steps of:

[0084] receiving a virus-free certificate request for a file;

[0085] identifying the file in a cache table, the cache table comprisingfor each identified file one or a plurality of virus-free certificates;

[0086] selecting in the cache table one virus-free certificate for theidentified file, using one or a plurality of anti-virus criteria;

[0087] retrieving from the cache table the selected virus-freecertificate;

[0088] sending back in response to the virus-free certificate requestthe retrieved virus-free certificate.

BRIEF DESCRIPTION OF THE DRAWING

[0089] Preferred embodiments of the present invention will now bedescribed by way of example only, with reference to the accompanyingdrawings in which:

[0090]FIG. 1 describes the different entities involved in the anti-virussystem according to the present invention.

[0091]FIG. 2 describes the content of a virus-free Certificate accordingto the present invention.

[0092]FIG. 3 describes the Virus-free Certificate Rules Table accordingto the present invention.

[0093]FIG. 4 describes the internal logic of a Virus-free CertificateFirewall according to the present invention.

[0094]FIG. 5 describes the Virus-free Certificate Cache Table accordingto the present invention.

[0095]FIG. 6 describes the internal logic of the Virus-free CertificateCache for retrieving a Virus-free Certificate according to the presentinvention.

[0096]FIG. 7 describes the internal logic of the Virus-free CertificateCache for updating a Virus-free Certificate according to the presentinvention.

[0097]FIG. 8 describes the different anti-virus entities in a Virus-freeCertificate Proxy environment according to the present invention.

[0098]FIG. 9 describes the Virus-free Certificate Proxy Table accordingto the present invention.

[0099]FIGS. 10a and 10 b describe the internal logic of the Virus-freeCertificate Proxy according to the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS OF THE INVENTION

[0100]FIG. 1 describes the different entities involved in the virussystem disclosed in the present invention. In most of the cases, thefile that the Client Workstation (101) requires is stored in a FileServer (for instance a WEB Server) (103). A Certificate is associatedwith this file on the File Server (103). The Certificate indicates thatthe file has been processed by a list of anti-virus programs (alsoreferred to as anti-virus checkers), and is virus free. It is an objectof the Virus-free Certificate Authority (VCA) (104) to build suchCertificates (called Virus-free Certificates-VC). The ClientWorkstation, the File Server, the Virus-fee Certificate Authority areattached to a LAN/WAN network (102) (Local Area Network/Wide AreaNetwork), which can include the Internet network.

[0101] The Client workstation (101) downloads the file and theassociated anti-virus Certificate from the File Server (103) through anetwork device within the WAN/LAN network. Said network device is forinstance:

[0102] an IP (Internet Protocol) Router which routes files between FileServers and Client Workstations,

[0103] a Firewall protecting the secure side of the LAN/WAN network(typically the Client Workstations attached to an Intranet network) fromthe unsecured side of the LAN/WAN network (typically the File Serversattached to the Internet network).

[0104] The network device controls and filters each file it receives,according to some anti-virus criteria. For that, it uses:

[0105] predefined rules, and

[0106] the virus-free Certificate associated with each file.

[0107] The network device therefore protects the Client Workstationsfrom viruses. This network device is called Virus-fee CertificateFirewall (also referred to as VCF) (105).

[0108] Depending on some predefined rules, a Virus-fee CertificateFirewall (VCF) may have to add a Virus-free Certificate to a file itreceives from a File Server. In this case, the Virus-free CertificateFirewall retrieves the virus-free Certificate from a Virus-freeCertificate Cache (VCC) (106). If the virus-free Certificate cannot beretrieved from a Virus-free Certificate Cache, the Virus-freeCertificate Firewall retrieves the Virus-free Certificate from aVirus-free Certificate Proxy (107).

[0109] A Virus-free Certificate Cache (VCC) (106) is used to storeexisting Virus-free Certificates within the LAN/WAN network. TheseVirus-free Certificates can be retrieved by systems attached to theLAN/WAN network (typically the Virus-free Certificate Firewall).Retrieving an existing Virus-free Certificate is more efficientoperation (in term of performance) than building a new Virus-freeCertificate. Multiple Virus-free Certificate Caches can be attached tothe LAN/WAN network. In this case, the multiple Virus-free CertificateCaches communicate across the LAN/WAN network in order to exchange theVirus-free Certificates.

[0110] A Virus-free Certificate Proxy (VCP) (107) acts as a singleVirus-free Certificate Authority (VCA) within the LAN/WAN network inorder to provide virus-free Certificates to any system attached to theLAN/WAN network. When multiple Virus-free Certificate Authorities (VCAs)are available (for instance, one VCA per software vendor), theVirus-free Certificate Proxy (VCP) identifies a Virus-free CertificateAuthority (VCA) which has authority for building a Virus-freeCertificate for of a particular file, and retrieves the Virus-freeCertificate from said identified Virus-free Certificate Authority (VCA).

[0111] Any system attached to the LAN/WAN network can retrieve avirus-free Certificate (VC) for a specific file from either:

[0112] A Virus-free Certificate Authority (VCA), which builds the VC.The virus-free Certificate (VC) is said to be “authoritative” becausethe Virus-free Certificate Authority (VCA) has authority to build avalid VC, using for instance the latest anti-virus programs and levels.

[0113] A Virus-free Certificate Proxy (VCP), which relays the requestfor virus-free Certificate (VC) to one or multiple Virus-freeCertificate Authorities (VCAs). Since a Virus-free Certificate Proxy(VCP) dynamically retrieves “authoritative” virus-free Certificates(VCs) from VCAs, it also provides “authoritative” virus-freeCertificates (VCs).

[0114] A Virus-free Certificate Cache (VCC). A VCC has no authority tobuild virus-free Certificates (VCs) but it maintains local copies ofvirus-free Certificates (VCs). Possibly, a virus-free Certificate (VC)retrieved from a Virus-free Certificate Cache (VCC) may be invalid. Forinstance, the virus-free Certificate (VC) is expired since it wasinitially built by a Virus-free Certificate Authority (VCA). AVirus-free Certificate Cache (VCC) does not provide “authoritative”virus-free Certificates (VCs).

[0115]FIG. 2 describes the content of virus-free Certificate (VC)according to the present invention. The virus-free Certificate reusesthe standard X.509 Certificate format. It comprises the signature of thefile and therefore is bound to this file. The main difference between aX.509 Certificate and the virus-free Certificate is that the virus-freeCertificate comprises:

[0116] an anti-virus name and level;

[0117] a signature of the file.

[0118] The virus-free Certificate (200) includes the following fields:

[0119] File name (201): This is the “name” of the file protected thatthe virus-free Certificate protects.

[0120] Issuer (202): This is the “name” of the third party that ussued/generated the virus-free Certificate. This third party is theCertificate Authority (CA).

[0121] Public Key Value (203): This is the public key of apublic/private key pair. An associated field defines the public keyalgorithm that must be used to check the file signature, for instance aRSA, Diffie-Hellman or DSA public key. The public key is provided by theVirus-free Certificate Authority. The corresponding private key is usedby the VCA to build the signature of files. So the same private/publickey pair may be used to build several virus-free Certificates from thesame issuer (VCA). This public key within the virus-free Certificate ispreferably used instead of the Virus-free Certificate Authority publickey used to validate only the present certificate signature and not thefile signature. A public key for decrypting the imbedded signature isadded within the virus-free Certificate because the Virus-freeCertificate Authority public key is generally longer and more complex.The validity of keys may also differ between the Virus-free CertificateAuthority public key and the virus-free Certificate public key. Anyway,because the virus-free Certificate is signed by the Virus-freeCertificate Authority, the use of the virus-free Certificate public keyis secure.

[0122] Validity (204): Two fields are used to define the period ofvalidity (valid from date 1 and valid to date 2).

[0123] Serial Number (205): This field provides a unique virus-freeCertificate serial number for the issuer.

[0124] Certificate Signature (206): The certificate signature is anencrypted digest generated by the Virus-free Certificate Authority (VCA)for authenticating the whole Certificate. The digest results from thehashing of the virus-free Certificate. The digest is encrypted using theVirus-free Certificate Authority (VCA) private key. The certificatesignature results from the encrypted digest and “certifies” that thefile signature is encrypted by the private key associated with thevirus-free certificate public key (203). The Virus-free CertificateAuthority (VCA) public key is different from the virus-free Certificatepublic key and is either preloaded in the web browser or given by atrusted entity. The VCA public key is used to retrieve the originalhashing of the full certificate. The Virus-free Certificate Authority(VCA) can use the same set of virus-free certificate private/public keys(203) for all the files generated during a given period of time so thecross-checking of the issuer authentication can be easily performed timeto time, when a new set of keys is used. Once the virus-free Certificatepublic key for a issuer is validated, it can be reused for several filescertified by the same issuer which reduces the number of virus-freeCertificate public keys.

[0125] File Signature (207): The File Signature is verified using thepublic key value given in the virus-free Certificate. The file signature(hashing) performed by the Virus-free Certificate Authority (VCA) on thefile is encrypted using the VCA private key. The original file signaturecan be retrieved using the VCA public key.

[0126] Anti-virus Checker (208): This field gives an indication of howthe virus-free Certificate has verified that the file was virus-free.The Anti-virus Checker comprises the name and the level of theanti-virus program. Several anti-virus programs and levels may beappended to reinforce the efficiency of the anti-virus detection.

[0127] Certificate Structure (209): This field describes the size andthe content of the virus-free Certificate fields. The number oranti-virus program is defined in this field.

[0128] If the virus-free Certificate uses a standard format (minimumsize of a virus-free Certificate), this field is optional.

[0129] If the size of the virus-free Certificate is above the size ofthe standard format (above the minimum size), this field is mandatoryand defines the size of the fields comprised in the virus-freeCertificate.

[0130]FIG. 3 describes the table used by the Virus-free CertificateFirewall (VCF) (105). Said table provides some indications forcontrolling and filtering the files received by the Virus-freeCertificate Firewall (VCF). This table is called Virus-free Certificate(VC) Rules Table (301).

[0131] The Virus-free Certificate Table (301) (a flat file in apreferred embodiment) is typically created by the Network Administratorin charge of the LAN/WAN network. This table associates with each filesome anti-virus criteria. Said anti-virus criteria are used by theVirus-free Certificate Firewall (VCF) for controlling and filtering ofeach file.

[0132] Each file is identified by its characteristics (303), which canbe one or a combination of the following information:

[0133] the source system which has originated the file,

[0134] the file name,

[0135] the file type,

[0136] optionally, the file size,

[0137] optionally, the file CRC (a file signature).

[0138] The anti-virus criteria (307) associated with each file comprise:

[0139] an information indicating whether or not a Virus-free Certificateis required for this file,

[0140] an information indicating a list of information comprised withina virus-free Certificate (VC) and that must be checked to determine thatthe virus-free Certificate (VC) is valid,

[0141] an information indicating whether or not the file must bediscarded, when a virus-free Certificate (VC) is required for this file,and when either:

[0142] no Virus-free Certificate is associated with the file, or

[0143] the Virus-free Certificate which is associated with the file, isnot valid.

[0144] a list of anti-virus programs and levels that must be used forbuilding the Virus-free Certificate associated with the received file.Typically, this list of anti-virus programs and levels is used by theauthority (a Virus-free Certificate Authority) which builds thevirus-free Certificate (VC).

[0145] The Virus-free Certificate Rules Table (301) comprises a list ofrecords (302). In order to minimize the number of records in the table,files having the same characteristics are grouped within file templates(303). The anti-virus criteria comprised within one record, apply to allfiles within the file template. There is one record for each filetemplate, each record comprising the following information:

[0146] (303) a File Template section, which comprises the followinginformation (fields in the record):

[0147] (304) File_Source: This is the identifier of the source system orthe plurality of source systems that have originated files. Forinstance, the File_Source can be the IP address of the File Server whichhas originated all files within a specific software company (forinstance the IP address of www.ibm.com File Server).

[0148] (305) File_Name. This is the name of one or multiple files. TheFile_Name can be either:

[0149] an explicit file name which identifies a unique file. Forinstance a File_Name with the value “setup1” identifies the file called“setup1”

[0150] a wildcarded file name which identifies multiple files. Forinstance, File_Name with the value “setup*” identifies any file whichname starts with “setup” (for instance “setup1”, “setup_ok”, . . . ).

[0151] (306) File_Type. This is the type of the file (for instance“exe”, “doc”, “avi”, “htm1”, . . . ). A File_Type identifies any file ofthis type. For instance, a File_Type with the value “exe” identifies allfiles which type is “exe” (for instance “start.exe”, “word.exe”, . . .).

[0152] Optionally, the File Template section can also comprise a filesize. The file size is then the size of all files within the same FileTemplate. The file size can possibly be used to differentiate fileshaving the same File_Source, File_Name, and File_Type.

[0153] Optionally, the File Template section can also comprise a fileCRC (a file signature). The file CRC is then the signature of the fileidentified by the File Template. The file CRC can possibly be used todifferentiate files having the same File_Source, File_Name, andFile_Type.

[0154] (307) a File Anti-virus Criteria section, which comprises thefollowing information (fields in the record):

[0155] (308) VC_Required. This information indicates whether or not aVirus-free Certificate must be associated with any file within the filetemplate. The possible values of VC_Required are “yes” and “no”.

[0156] (309) Valid_VC_Required. This information indicates the list ofinformation comprised within a virus-free Certificate (VC) and whichmust be validated by the Virus-free Certificate Firewall (VCF) in orderto determine that the virus-free Certificate (VC) is valid. Forinstance, a virus-free Certificate (VC) with an expired date may beconsidered as valid. This information applies to any file within thefile template. By default, all information comprised within a virus-freeCertificate (VC) must be checked and validated by the Virus-freeCertificate Firewall (VCF) in order to determine that the virus-freeCertificate (VC) is valid.

[0157] (310) File_Discard. This information indicates whether or not thefile must be discarded, when “VC_Required” is set to “yes”, and wheneither:

[0158] no Virus-free Certificate is associated with the file, or

[0159] the Virus-free Certificate which is associated with the file, isnot valid. The possible values are “yes” and “no”.

[0160] (311) Required_AV_Checker_List. This is the list of anti-virusprograms and levels which must be used for the anti-virus processing ofany file within the file template. Said list is therefore the list ofanti-virus programs and levels that must be used by the authority(typically a VCA) which builds the Virus-free Certificate associatedwith any file within the file template.

[0161] A default record is defined in the Virus-free Certificate RulesTable. This default record comprises anti-virus criteria that must beused by the Virus-free Certificate Firewall (VCF) for processing fileswhich are not explicitly listed in a specific record.

[0162] According to the present invention, a purpose of a Virus-freeCertificate Firewall (VCF) is to control and filter each file itreceives, according to some anti-virus criteria and using Virus-freeCertificates. For each file it receives, the Virus-free CertificateFirewall (VCF) performs the following operations:

[0163] retrieving the anti-virus criteria for said received file, fromthe Virus-free Certificate Rules Table (301),

[0164] checking whether or not said received file is associated with aVirus-free Certificate,

[0165] checking whether or not the Virus-free Certificate which isassociated with said received file, is valid, based on said anti-viruscriteria,

[0166] when required by said anti-virus criteria, retrieving a validVirus-free Certificate associated with said file. Typically, saidVirus-free Certificate is retrieved either from a Virus-free CertificateAuthority (VCA), or from Virus-free Certificate Cache (VCC) or from aVirus-free Certificate Proxy (VCP),

[0167] discarding the file, when the anti-virus criteria are notsatisfied.

[0168] forwarding the file, possibly along with its associated validVirus-free Certificate, when the anti-virus criteria are satisfied.

[0169] Typically, the Virus-free Certificate Firewall (VCF) is either adedicated network device attached to the LAN/WAN network, or an existingnetwork device (for instance an existing Firewall) which is enhanced toprovide the Virus-free Certificate Firewall (VCF) functions.

[0170]FIG. 4 is a flow chart which refers to the internal logic of theVirus-free Certificate Firewall (VCF). The VCF:

[0171] (401): receives a file

[0172] (402): retrieves the anti-virus criteria associated with thefile, from the Virus-free Certificate Rules Table (403). Said fileanti-virus criteria are comprised in the VC Rules Table record which isassociated with the received file. Said record is identified using its“File_Source”, “File_Name”, and “File_Type” fields, and usinginformation retrieved from the received file (its name, its type, andits source which is typically identified by the IP address of the systemwhich originated the file). Typically, the anti-virus criteria arecomprised in the fields (“VC_Required”, “Valid_VC_Required”,“File_Discard”, and “Required_AV_Checker_List”) of the file anti-viruscriteria section of the identified record.

[0173] (404): tests whether or not a Virus-free Certificate (VC) isassociated with the received file. Preferably, the virus-freeCertificate (VC) has been received within the file through separatemeans.

[0174] If a virus-free Certificate (VC) is found:

[0175] (405) tests whether or not the received virus-free Certificate(VC) is valid. Typically, and by default, the VC is valid when all thefollowing conditions are satisfied:

[0176] The VCA which has issued the VC, and identified by the “issuer”field of the VC, is a trusted VCA. Typically, this is done by checkingthat the VCA is comprised within a list of trusted VCAs. This list isconfigured on the VCF by a Network Administrator.

[0177] The VC is authenticated using:

[0178] its “certificate signature” field and

[0179] the public key of the VCA which has issued the VC. Typically, theVCF retrieves said public key from a list of trusted VCA certificateswhich have been placed on the VCF by a Network Administrator, or whichhave been retrieved by the VCF through secure means.

[0180] The VC date is correct. Typically, the current date is comprisedin the date interval provided in the “validity” field.

[0181] The VC has not been revoked. Typically, this is done using:

[0182] the “issuer” and the “serial number” field of the VC, and

[0183] a certificate revocation list (CRL) issued by the VCA.

[0184] Possibly, the “Valid_VC_Required” indication retrieved from theVC Rules Tables in step (402), indicates the list of the aboveconditions that must be satisfied. For instance, “Valid_VC_Required” mayindicate that a VC with an expired date is considered as valid.

[0185] If the virus-free Certificate (VC) is valid:

[0186] (406) tests whether or not the anti-virus processing of the fileis OK. This anti-virus processing consists in checking that the VCAwhich issued the VC has tested the file for viruses. This checking usesat least the list of required anti-virus programs and levels comprisedin the file anti-virus criteria.

[0187] The list (Listl) of anti-virus programs and levels used by theVCA to test the file for viruses is retrieved from the “anti-viruschecker” fields of the VC.

[0188] The list (List2) of anti-virus programs and levels that must beused to test the file for viruses, is retrieved from the“Required_AV_Checker_List” field of the file anti-virus criteria sectionof the selected record (said selected record has been retrieved in (402)from the VC Rules table).

[0189] By default, the anti-virus processing is OK when List2 is asubset of List1. Possibly, the “Valid_VC_Required” indication which hasbeen retrieved from the VC Rules Tables in step (402), indicates if theanti-virus processing is OK when:

[0190] Both List1 and List2 are identical, or

[0191] List2 is a subset of Listl (this is the default).

[0192] If the anti-virus processing is OK:

[0193] (407) tests whether or not the file signature is OK. This testcompares the file signature calculated by the VCF and the file signaturecomprised within the VC (in the “file signature” field). If both are thesame, then the file signature is OK, which means that the received filehas not been modified since it was checked for viruses by the VCA.

[0194] If the file signature is OK:

[0195] (408) updates a Virus-free Certificate (VC) Cache. An updatedrequest comprising the file VC, is sent to a VC Cache by the VCF. Saidrequest typically comprises the file name and type, the file size, thefile CRC, and the file Virus-free Certificate. Preferably, the addressof a VC Cache is a predefined parameter of the VCF.

[0196] This step is optional, and is obviously only done when a VC Cachehas been defined within the LAN/WAN network.

[0197] (409) forwards the received file, along with its valid VC. TheVCF then waits for the next file to process in (401).

[0198] If the file signature is OK:

[0199] (410) stores an information indicating that the file signature isnot OK (or any other detected error).

[0200] (411) retrieves a VC from a Virus-free Certificate (VC) Proxy.The VCF sends a request to a VC Proxy, in order to retrieve a VCassociated with the received file. Said VC is authoritative since it isbuilt and issued by a VCA. Possibly, the VCF retrieves an authoritativeVC directly from a VCA, when no VC Proxy is defined within the LAN/WANnetwork. Said request typically comprises:

[0201] The file name and type, the file size (optional), and the fileCRC.

[0202] Optionally, a reduced VC which contains the “issuer” information.Said “issuer” information identifies the preferred VCA, and provides theVCP with some selection criteria which can be used when multiple VCs areavailable for the same file (typically, one VC per VCA).

[0203] Optionally, a list of anti-virus checkers, that should preferablybe used by the VCA to build the VC.

[0204] Preferably, the address of the VC Proxy (or VCA) is a predefinedparameter of the VCF.

[0205] (412) tests whether or not a valid VC has been retrieved. A VCmay have been retrieved from the VCP (or VCA) in step 411. Said VC istested to make sure it is valid and has not been corrupted for instanceby a malicious system stealing the identity of a trusted VCA. The VC isvalidated using the same criteria and possibly the “Valid_VC_Required”indication, as in steps (405), (406), and (407). Typically, the testdetermines that:

[0206] The VCA which has issued the VC is a trusted VCA.

[0207] The VC is authenticated.

[0208] The VC date is correct

[0209] The VC has not been revoked

[0210] The anti-virus processing is OK.

[0211] The file signature is OK.

[0212] If a valid VC has been retrieved:

[0213] (408) updates a Virus-free Certificate (VC) Cache.

[0214] (409) forwards the received file, along with its valid VC. TheVCF then waits for the next file to process in (401).

[0215] If a valid VC has not been retrieved:

[0216] (413) discards the file, and stores an information whichindicates the discard and that a valid VC has not been retrieved. TheVCF then waits for the next file to process in (401).

[0217] If the anti-virus processing is not OK:

[0218] (414) tests whether or not the VC has been retrieved from a VCCache. The information indicating that the VC has been retrieved from aVC Cache is set in step (420).

[0219] If the VC has been retrieved from a VC Cache (in step (420))

[0220] Continues in step (410), in order to possibly retrieve anauthoritative VC from a VC Proxy (or VCA).

[0221] If the VC has not been retrieved from a VC Cache

[0222] Continues in step (416), in order to possibly retrieve a VC froma VC Cache.

[0223] If the VC is not valid:

[0224] Continues in step (414), in order to possibly retrieve a validVC, either from a VC Proxy (or VCA) or from a VC Cache.

[0225] If a VC is not found:

[0226] (415) tests whether or not a VC is required for the receivedfile. The test uses the “VC”Required” indication retrieved from the VCRules Table in step (402)

[0227] If a VC is required for the received file:

[0228] (416) stores an information indicating an error condition.Possibly, a file which should have a VC has been received without a VC,or a file has been received with an invalid VC.

[0229] (417) tests whether or not the file must be discarded. The testuses the “File_Disard” indication retrieved from the VC Rules Table instep (402). The file must be discarded when “File_Discard” is set to“Yes”, and when “VC_Required” is set to “yes”, and when either:

[0230] no VC is associated with the file, or

[0231] the VC which is associated with the file, is not valid.

[0232] If the file must be discarded:

[0233] (418) discards the file, and stores an information whichindicates the discard. The VCF then waits for the next file toprocession (401).

[0234] If the file must not be discarded.

[0235] (420) retrieves a VC from a Virus-free Certificate (VC) Cache.The VCF sends a request to a VC Cache, in order to retrieve a VCassociated with the received file. Said request typically comprises:

[0236] The file name and type, the file size (optional), and the fileCRC.

[0237] Optionally, a reduced VC which contains the “issuer” information.Said “issuer” information identifies the preferred VCA, and provides theVCC with some selection criteria which can be used when multiple VCs areavailable for the same file (typically, one VC per VCA).

[0238] Optionally, a list of anti-virus checkers. Said list indicatesthe list of anti-virus checkers that should preferably be used to buildthe VC, and provides, the VCC with some selection criteria which can beused when multiple VCs are available for the same file (typically, oneVC per VCA).

[0239] Preferably, the address of the VC Cache is a predefined parameterof VCF. This step is optional, and is obviously only done when a VCCache has been defined within the VCF.

[0240] (421) tests whether or not a VC has been retrieved from a VCCache:

[0241] If a VC has been successfully retrieved from a VC Cache:

[0242] Continues in step (405) in order to validate the retrieved VC.Since the VC has been retrieved from a VC Cache, the VC is notauthoritative and must be validated. An indication that the VC has beenretrieved from a VC Cache is also stored for internal use (in step(414)).

[0243] If a VC has not been successfully retrieved form a VC Cache:

[0244] Continues in step (411) in order to retrieve an authoritative VCfrom a VC Proxy (or from a VCA).

[0245]FIG. 5 describes the table used by the Virus-free CertificateCache (VCC) (106). This table, called Virus-free Certificate CacheTable, is dynamically built by the VCC and comprises a local copy ofVirus-free Certificate which have been transmitted through the LAN/WANnetwork. The table (501) comprises for each file, one or multipleassociated Virus-free Certificates.

[0246] In the VC Cache Table (501), each file is identified by itscharacteristics (503), which are:

[0247] the file name,

[0248] the file type,

[0249] optionally, the file size,

[0250] the file CRC.

[0251] In the VC Cache Table, each file is associated with one ormultiple VC sections (508), each VC section comprising the followinginformation:

[0252] The VC associated with this file,

[0253] The date of the latest request to retrieve said VC,

[0254] The number of request (hits) to retrieve said VC.

[0255] The table comprises a list of records (502). There is one recordfor each file, each record comprising the following information:

[0256] (503) a File section comprising the following information (fieldsin the record):

[0257] (504) File_Name. This is the name of the file. Typically, this isthe explicit file name. For instance, a File_Name with the value“setup1” identifies the file called “setup1”

[0258] (505) File_Type. This is the type of the file (for instance“exe”, “doc”, “avi”, “htm1”, . . . ).

[0259] (506) File_Size. This is the size of the file. This field isoptional.

[0260] (507) File_CRC. This is the CRC (a file signature) of the file.The combination of File_Name and File_Type may identify in a unique wayone file. If multiple files have the same name and type (for instance,multiple “setup.exe” files originated from multiple sources), each oneof these said files may then be differentiated in a unique way by itsfile size (for instance the size of one “setup.exe” is 2 kilobytes, andthe size of another “setup.exe” is 4 kilobytes).

[0261] If multiple files have the same name, type, and size, each one ofthese said files is then differentiated in a unique way by its file CRCwhich is a file signature (hashing)

[0262] (508) a Virus-free Certificate (VC) section comprising thefollowing information (fields in the record):

[0263] (509) Virus-free_Certificate (VC). This is the VC associated withthe file.

[0264] (510) Last_Date. This is the date of the latest request receivedb the VC Cache to retrieve or to update this VC. Typically, this date isused when the VC Cache is maintained and when for instance the oldestrecords have to be deleted.

[0265] (511) Number_Hits. This is the number of requests (hits) thathave been received by the VC Cache to retrieve this VC. Typically, thisnumber of hits is used when the VC Cache is maintained and when forinstance the records with the lowest number of hits have to be deleted.

[0266] Possibly, multiple VC sections are associated with one filewithin the same record to support multiple VCs per file. This is forinstance necessary when one file has one VC per VC Authority (VCA), eachVC Authority using for instance one specific anti-virus program. In thiscase, each record is still identified by its File section, but multipleVC sections are then associated with said File section (one VC sectionper VC).

[0267] According to the present invention, a Virus-free CertificateCache (VCC) (106) stores existing Virus-free Certificate within theLAN/WAN network. Said existing Virus-free Certificates can then beretrieved by systems attached to the LAN/WAN network (typically theVirus-free Certificate Firewall). Retrieving an existing Virus-freeCertificate is more efficient than building a new Virus-freeCertificate, and therefore provides better performance.

[0268] Multiple Virus-free Certificate Caches can be attached to theLAN/WAN network. In this case, the multiple VCCs communicate across theLAN/WAN network in order to exchange the Virus-free Certificates.

[0269] The VC Cache performs the following functions:

[0270] Storing copies for each file of the Virus-free Certificate (VC)or of the multiple Virus-free Certificates in a VC Cache Table.

[0271] Processing each request for updating the VC Cache Table with anew Virus-free Certificate. This operation comprises the steps of:

[0272] Dynamically updating a local VC Cache Table with a copy of saidnew Virus-free Certificate.

[0273] Possibly updating one or multiple remote VC Cache Tables withsaid new Virus-free Certificate.

[0274] Processing each request for retrieving a VC associated with aspecific file. This operation comprises the steps of:

[0275] Preferably retrieving a VC from a local VC Cache Table.

[0276] Possibly retrieving a VC from a remote VC Cache Table.

[0277] Maintaining the VC Cache Table, by discarding from the VC CacheTable the invalid VCs.

[0278] Possibly pre-loading the VC Cache Table with one or multiple VCswhich are directly retrieved from one or multiple VC Authorities or VCProxies.

[0279] Furthermore, the operation of preferably retrieving a VC from alocal VC Cache Table, comprises the following steps:

[0280] Identifying a preferred VC in the VC Cache Table, using one ormultiple selection criteria, said selection criteria comprising:

[0281] the name of said specific file,

[0282] the type of said specific file,

[0283] optionally the size of said specific file,

[0284] the CRC of said specific file,

[0285] optionally a preferred list of anti-virus programs and levels,

[0286] optionally the identifier of a preferred VCA.

[0287] Retrieving said preferred VC from the VC Cache Table.

[0288] Typically, the VCC is either a dedicated network device attachedto the LAN/WAN network, or an existing network device (for instance anexisting WEB Proxy system) which is enhanced to provide the VCCfunctions.

[0289] The VCC periodically maintains the VC Cache Table. This operationcomprises the following steps:

[0290] Checking the validity of each VC in the VC Cache Table using theVC fields. Typically, this checking uses the “validity” and the “serialnumber” fields of the VC to determine if the VC has expired or if the VChas been revoked.

[0291] Discarding from the local VC Cache Table:

[0292] each VC section with an invalid VC,

[0293] Each record with no VC section.

[0294] The VC Cache Table maintenance is preferably performed at regulartime intervals, for instance every night. The maintenance process can betriggered either automatically or manually. The periodicity of saidmaintenance is for instance a predefined parameter of the VCC.

[0295] Optionally, the VC Cache can discard in one or multiple remote VCCache Tables, records comprising a VC which is no longer valid. Thisoperation is optional since preferably each VCC maintains its own localVC Cache Table, in order to avoid unnecessary traffic across the LAN/WANnetwork.

[0296] The VC Cache can pre-load its local VC Cache Table with one ormultiple VCs directly retrieved from one or multiple VC Authorities(VCAs) or VC Proxies (VCPs). In this case, the VC Cache is configured(typically by a Network Administrator) with a list of VCAs (or VCPs).The VC Cache periodically retrieves VCs from the VCAs within said list,and populates the VC Cache Table with record comprising said retrievedVCs.

[0297] Typically, the VC Cache can retrieve from a VCA one file (forinstance using FTP) comprising the latest VCs created by said VCA. TheVC Cache then creates one record in the VC Cache Table, for each VCcomprised within said retrieved file. The pre-loading of the VC CacheTable is preferably performed at regular time interval, for instanceevery night. The pre-loading process can be triggered eitherautomatically or manually. The periodicity of said pre-loading is forinstance a predefined parameter of the VCC.

[0298]FIG. 6 is a flow chart which refers to the internal logic of theVirus-free Certificate Cache (VCC) and more particularly to the methodfor processing a request for retrieving a VC for a particular file. TheVirus-free Certificate Cache (VCC):

[0299] (601): receives a request to retrieve a VC for a particular file.Typically, said request for VC typically comprises:

[0300] The name, and type of the file,

[0301] The size of the file (optionally),

[0302] The CRC of the file. This is a file signature identifying thefile.

[0303] Optionally, the list of anti-virus programs and levels (referredto as “RCV_AV_Checker_List”), that should preferably be comprised withinthe list of anti-virus programs and levels which have been used to buildthe requested VC. Typically, this information is used by the VCC toselect the preferred VC, when multiple VCs are available for the samefile.

[0304] Possibly, the list is empty, which means that any anti-virusprogram and level can be used.

[0305] Optionally, a reduced VC comprising only the “issuer” field(referred to as “RCV_issuer”), and identifying the preferred VCA. Thereduced VC then provides the VCC with some selection criteria. Theseselection criteria can be used when multiple VCs are available for thesame file (typically, one VC available per VCA).

[0306] (602) retrieves one VC from the VC Cache Table (603).

[0307] Typically, this operation comprises the following step:

[0308] Selecting one record (called “Record_S”) within the VC CacheTable, using:

[0309] Its File_Name and File_Type, which must be identical to the filename and file type comprised in the received request.

[0310] If multiple records (files) have the same File_Name and File_Type(for instance, multiple “setup.exe” files originated from multiplesources), each record (file) can then be differentiated in a unique wayby using the File_Size (for instance the size of one “setup.exe” is 2kilobytes, and the size of another “setup.exe” is 4 kilobytes).

[0311] In the unlikely event of multiple records (files) having the sameFile_Name, File_Type, and File_Size, each record (file) is thendifferentiated in a unique way by using the File_CRC.

[0312] Selecting one VC within said selected record:

[0313] When only one VC section is comprised within “Record_S”, theselected VC is the VC comprised within said VC section.

[0314] When multiple VC sections are comprised within “Record_S”, eachone comprising one VC, the selected VC is preferably identified using:

[0315] The “issuer” field of the VC. This issuer field is equal (orcomprises) the “RCV_issuer” possibly received in the request.

[0316] The “Anti-virus Checker” fields of the VC. These Anti-virusCheckers are equal (or comprise) the “RCV_AV_Checker_List” possiblyreceived in the request.

[0317] (604) tests whether or not a VC has successfully been retrievedfrom the VC Cache Table.

[0318] If a VC has been retrieved from the VC Cache Table

[0319] (605) updates in the VC Cache Table (603), the “Last_Date” andnumber_Hits” fields of the VC section comprising the VC.

[0320] Updates “Last_Date” with the current date

[0321] Increments “Number_Hits”.

[0322] (606) answers the received request for VC, with a positiveresponse comprising the retrieved VC. Optionally, the VC is validatedbefore being sent back in the response. The VCC then waits for the nextrequest for VC.

[0323] If a VC has not been retrieved from the VC Cache Table

[0324] (607) retrieves the VC from a remote VC Cache. The VCC forwardsthe received request to one or multiple VC Caches. The address of saidVC Caches is typically a predefined parameter of the VCC.

[0325] (608) tests whether or not a VC has been retrieved from a remoteVC Cache.

[0326] If a VC has successfully been retrieved from a remote VC Cache:

[0327] (609) stores said retrieved VC in the VC Cache Table. Either anew record is created in the VC Cache Table, or a new VC section iscreated in an existing record.

[0328] (606) answers the received request for VC, with a positiveresponse comprising the VC which has been retrieved. Optionally, the VCis validated before being sent back in the response. The VCC then waitsfor the next request for VC.

[0329] If a VC has not been retrieved from a remote VC Cache:

[0330] (610) answers the received request for VC, with a negativeresponse since no VC has been retrieved. The VCC then waits for the nextrequest for VC.

[0331]FIG. 7 is a flow chart which refers to the internal logic of theVirus-free Certificate Cache (VCC) and more particularly to a method forprocessing a request to update the VC Cache Table. The Virus-freeCertificate Cache Table (VCC):

[0332] (701): receives a request to update the VC Cache Table, with a VCassociated with a particular file. Typically, said request for VCtypically comprises:

[0333] The name, and the type of said file,

[0334] The size of the file (optionally),

[0335] The CRC of the file. This is a file signature which identifiesthe file.

[0336] The VC.

[0337] (702) tests whether or not the received VC is valid.

[0338] The received VC is checked to be sure it is valid and has notbeen corrupted for instance by a malicious system sending corrupted VCs.Typically, the following VC validation is processed:

[0339] The VC is authenticated using its “certificate signature” file,

[0340] The VC “validity” is correct,

[0341] The VC has not been revoked.

[0342] If the received VC is valid:

[0343] (704) tests whether or not the VC Cache Table is full:

[0344] If the VC Cache Table is full:

[0345] (705) deletes some record of the VC Cache Table (706). Typically,the records which are deleted are selected according to the “Last_Date”and “Number_Hits” fields. For instance, the records having the oldest“Last_Date” and the lowest “Number_Hits” are deleted.

[0346] (707) updates the VC Cache Table (706), with the received VC.Either a new record is created in the VC Cache Table, or a new VCsection is created in an existing record.

[0347] (708) updates one or multiple remote VC Caches. The VCC forwardsthe received request to one or multiple VC Caches. The address of saidVC Caches is typically a predefined parameter of the VCC. This step isobviously bypassed when no remote VC Cache is defined.

[0348] If the VC Cache Table is not full:

[0349] Continues in step (707) to update the VC Cache Table with thereceived VC.

[0350] If the received VC is not valid:

[0351] (703) stores an information indicating that a request for VCCache update has been received with an invalid VC, and discards therequest.

[0352] The Virus-free Certificate Proxy (VCP) (107) acts as a singleVirus-free Certificate Authority (VCA) within the LAN/WAN network inorder to provide Virus-free Certificates to any system attached to theLAN/WAN network. When multiple VCAs are available (for instance, one VCAper software provider), the VCP identifies a VCA which has authority tobuild a Virus-free Certificate (VC) for a particular file, and retrievessaid Virus-free Certificate (VC) from said identified VCA.

[0353] A VC Proxy is a method and system for retrieving a VC for aparticular file, from one or multiple VCAs. A VC Proxy processesrequests for VCs (a request for VC is a request to retrieve one VC for aparticular file). The method of processing each received request for VCcomprises the steps of:

[0354] Identifying a VCA which has authority to build a VC for saidparticular file,

[0355] Retrieving said VC from said identified VCA,

[0356] When said requested VC has been retrieved, answering the receivedrequest for VC, with a positive response comprising said VC.

[0357] Furthermore, the step of identifying a VCA which has authority tobuild a VC for a particular file, comprises the further steps of:

[0358] Retrieving the identifier of the VCA, using information comprisedwithin the received request for VC, or

[0359] Identifying the VCA using

[0360] information comprised within the received request for VC, and

[0361] information retrieved from a configured VC Proxy Table.

[0362] If no VCA is identified:

[0363] Identifying a Virus-free Certificate Relay (VCR) system, whichcan provide the identifier of a VCA.

[0364] Retrieving from said identified Virus-free Certificate Relay(VCR) system, the identifier of a VCA which has authority to build saidVC.

[0365] If no VCR system is identified,

[0366] identifying a configured default VCA using information retrievedfrom a configured VC Proxy Table.

[0367] Furthermore, the step of identifying a Virus-free CertificateRelay (VCR) system, which can provide the identifier of a VCA which hasauthority to build said VC, comprises the further steps of:

[0368] Retrieving the identifier of a Virus-free Certificate Relay(VCR), from information comprised within said received request for VC,or

[0369] Identifying a Virus-free Certificate Relay (VCR) system usinginformation comprised within said received request for VC, and usinginformation retrieved from a configured VC Proxy Table.

[0370] Furthermore, the step of retrieving said VC for said specificfile from said identified VCA, consists in either:

[0371] Retrieving the VC, using a short request sent to said identifiedVCA and which does not comprise said specific file; or

[0372] Retrieving the VC, using a full request sent to said identifiedVCA and which comprises said specific file.

[0373] Typically, the VCP is either a dedicated network device attachedto the LAN/WAN network, or an existing network device (for instance anexisting WEB Server) which is enhanced to provide the VCP functions.

[0374]FIG. 8 depicts the logical anti-virus entities involved in a VCProxy environment. All the systems are attached to the LAN/WAN network(802). The WAN may be for instance the Internet network, or/and acompany private Intranet network. One or multiple Virus-free CertificateAuthorities (VCAs) (804) are attached to the LAN/WAN network (802). Theyhave authority to build Virus-free Certificates (VCs). Typically, eachVCA has authority to build the VCs associated with specific files. Therecan be:

[0375] one VCA for each software provider (companies such as IBM,Symantec). For instance, IBM may provide and attach one VCA to theInternet, in order to build VCs associated with any file owned by IBM(for instance, any software package such as “Host On Demand”). Forinstance, the Symantec company may attach one VCA to the Internet, inorder to build a VC associated with any ant-virus product update (suchas a virus signature file).

[0376] one VCA for each company having authority to build VCs for filesowned by other software providers. Such VCA builds VCs on behalf ofsoftware providers, for any or for specific files owned by said softwareproviders. For instance, the VeriSign company may provide and attach oneVCA to the Internet in order to build VCs for any (or specific) fileowned by IBM.

[0377] one VCA internal to the private Intranet network of a softwareprovider. Such VCA has for instance authority to build the VC associatedwith specific or any file transmitted across the Intranet part of theLAN/WAN network.

[0378] In addition to these VCAs (804), one or multiple Default VCAs(803) may be attached to the LAN/WAN network. These Default VCAs haveauthority to build a VC for any file received by any system attached tothe LAN/WAN network. Typically, when a system attached to the LAN/WANnetwork requires a VC for a particular file, and when no VCA (804) isexplicitly identified, the Default VCA is used to build this VC.

[0379] Software providers (for instance small companies) which do notprovide their own VCA, may have an agreement with other companiesproviding VCAs. These software providers have to indicate the identifierof one or multiple VCAs having authority to build a VC associated withone or multiple files they own. This indication is then provided by asystem called Virus-free Certificate Relay (VCR) (805).

[0380] A Virus-free Certificate Relay (VCR) (805) is therefore a systemwhich provides the identifier of one or multiple VCAs having authorityto build a VC for one or multiple files. Typically, a VCR is a FileServer (for instance an FTP Server) which originates files owned by asoftware provider, and which indicates the VCA that can be used to builda VC associated with each file.

[0381] For instance, a small software provider may indicate on its VCR(typically a FTP server) that the VCs associated with its softwarepackages can be built by one specific VCA (for instance VeriSign). Anysystem requiring a VC for one of these software packages can thencontact the indicated VCA to retrieve said VC.

[0382]FIG. 9 describes the table used by the Virus-free CertificateProxy (VCP) (801).

[0383] Said table (901) (a flat file in a preferred embodiment) ispreferably created by the Network Administrator in charge of the LAN/WANnetwork. The Virus-free Certificate Proxy Table (901):

[0384] associates each file provider (for instance any software providersuch as IBM), with:

[0385] the identifier of one or multiple VCAs having authority to buildone or multiple VCs associated with one or multiple files originated bysaid file provider.

[0386] the identifier of one or multiple VCRs capable of providing theidentifier of one or multiple VCAs having authority to build one ormultiple VCs associated with one or multiple files originated by saidfile provider.

[0387] optionally associated one or multiple files, with:

[0388] the identifier of one or multiple VCAs having authority to buildone or multiple VCs associated with each one of said files.

[0389] the identifier of one or multiple VCRs capable of providing theidentifier of one or multiple VCAs having authority to build one ormultiple VCs associated with each one of said files.

[0390] In the VC Proxy Table, each file provider is identified by itscharacteristics (903). These characteristics comprise:

[0391] The file provider identifier (typically its name).

[0392] Optionally, in the VC Proxy Table, each file (or group of files)is identified by its characteristics (905). These characteristicscomprise:

[0393] The file identifier,

[0394] Optionally, the file name, the file type, the file size, and thefile CRC.

[0395] In the VC Proxy Table, each file provider, and optionally eachfile (or group of files), is associated with one or multiple VCAsections. Each VCA section comprises the following information:

[0396] A VC Authority (VCA) identifier,

[0397] A VC Relay (VCR) identifier,

[0398] Optionally, a list of anti-virus programs and levels which areused by said VCA.

[0399] The table comprises a list of records (902). There is one recordfor each file provider, and optionally one record for each file (orgroup of files), each record comprising the following information:

[0400] (903) a File Provider section, which comprises the followinginformation (fields in the record):

[0401] (904) File_Provider. This is the identifier of the softwareprovider which originates one or multiple files. Typically, saididentifier is the company name of the software provider (for instanceIMB Corp.).

[0402] (905) an optional File Template section, which identifies one ormultiple files having the same characteristics. Said characteristicscomprise the following information (fields in the record):

[0403] (906) File_Identity. This is the identifier of one or multiplefiles within the file template, which has been originally created by thesoftware provider when it has created said one or multiple files.Typically, said identifier is imbedded within each file by the fileprovider when the file is created. Said identifier typically comprisesthe original file name, version, and language.

[0404] (907) File_Name. This is the name of one or multiple files. TheFile_Name can be either:

[0405] an explicit file name which identifies a unique file. Forinstance a File_Name with the value “setup1” identifies the file called“setup1”.

[0406] a wildcarded file name which identifies multiple files. Forinstance, File_Name with the value “setup*” identifies any file whichname starts with “setup” (for instance “setup1”, “setup_ok”, . . . ).

[0407] (908) File_Type. This is the type of the file (for instance“exe”, “doc”, “avi”, “htm1”, . . . ). A File_Type identifies any file ofthis type. for instance, a File_Type with the value “exe” identifies allfiles which type is “exe” (for instance “start.exe”, “word.exe”, . . .).

[0408] (909) File_Size. This is the size of the file.

[0409] (910) File_CRC. This is the CRC (a file signature) of the file.

[0410] In most cases, the File_Identity field provides sufficientinformation to identify in a unique way one file template. File_Name,File_Type, File_Size, and File_CRC are therefore optional in the FileTemplate section.

[0411] When File_Identity however, does not identify in a unique way afile template (or when the File_Identity cannot be retrieved for aspecific file), the combination of File_Name and File_Type may identifyin a unique way a file.

[0412] If multiple files have the same name and type (for instance,multiple “setup.exe”files originated from multiple sources), each filemay then be differentiated in a unique way by its file size (forinstance the size of one “setup,exe” is 2 kilobytes, and the size ofanother “setup.exe” is 4 kilobytes).

[0413] In the unlikely event of multiple files having the same name,type, and size, each file is then differentiated in a unique way by itsfile CRC which is the file signature.

[0414] (911) a Virus-free Certificate Authority (VCA) section, whichcomprises the following information (fields in the record):

[0415] (912) VCA_Id. This is the identifier of a VC Authority associatedwith the File Provider (and optionally with the file template), andwhich therefore has authority to build one or multiple VCs for each fileoriginated by said File Provider. Typically, this is the IP address ofthe VCA.

[0416] (913) VCR_Id. This is the identifier of a VC Relay associatedwith the File Provider (and optionally with the file template), andwhich therefore can provide the identifier of one or multiple VCAshaving authority to build a VC for one or multiple files originated bysaid File Provider. Typically, this is the IP address of the VCR.

[0417] (914) AV_Checker_List. This is the list of anti-virus programsand levels used by the VCA identified by VCA_Id when it builds VCs. Thisfield is typically empty by default, which means that said list isunknown.

[0418] One record typically comprises one VCA section. However, onerecord possibly comprises multiple VCA sections, if one File Providerhas multiple VCAs (for instance, one VCA per anti-virus program).

[0419] The VC Proxy Table comprises one default record, which comprisesthe identifier (VCA_Identifier) of a Default VCA. Possibly, multipleDefault VCAs can be defined.

[0420]FIGS. 10a and 10 b are flow charts which refer to the internallogic of the Virus-free Certificate Proxy (VCP). The VCP:

[0421] (1001): receives a request to retrieve a VC for a particularfile. Typically, said request for VC comprises:

[0422] One particular file,

[0423] The name, and the type of this file,

[0424] A list of anti-virus programs and levels (referred to as“RCV_AV_Checker_ List”), that must be used to build the VC. The list maybe empty, which means that any anti-virus program and level can be used.

[0425] Optionally, a reduced VC which only comprises the “issuer” field(referred to as “RCV_issuer”), and which identifies the preferred VCA.Said reduced VC provides the VCP with some selection criteria which canbe used when multiple VCs are available for the same file (typically,one VC available per VCA).

[0426] (1002) tests whether or not the identifier of a VCA that can beused to retrieve a VC, is comprised within the received request for VC.Said identifier is then referred to as “VCA_S_Id”. Typically, said VCAidentifier may be imbedded within the received file (for instance in the“organization” section), or possibly derived from any informationretrieved from the received request.

[0427] If VCA_S_Id is retrieved from information comprised within thereceived request:

[0428] (1003) retrieves one VC associated with the received file fromthe VCA identified by VCA_S_Id, using a short request. The VCP sends ashort request to the VCA identified by VCA_S_Id, in order to retrieve aVC associated with the received file. Said short request does notcomprise the received file, in order to minimize the traffic across theLAN/WAN network. Typically, said short request for VC comprises thefollowing information:

[0429] The file name, and file type of the received file.

[0430] The size of the received file,

[0431] The CRC of the received file. Typically, the file CRC iscalculated using the received file.

[0432] The list of anti-virus programs and levels that must be used bythe VCA to build the VC. This list may be empty, which means that anyanti-virus program and level can be used.

[0433] Typically, this list is the list which was received in therequest (“RCV_AV Checker_List”). Possibly, this list can also be acombination of “RCV_AV_Checker_List” and some configuration informationof the VCP (for instance a Network Administrator may want to enforce aspecific and updated list of anti-virus programs and levels that must beused to build the VC). Typically, the VCA_S_Id comprises the address(for instance the IP address) of the VCA. Possibly, when no specific VCAcan be identified in a unique way, said short request can be sent(broadcast) to all available VCAs.

[0434] (1004) tests whether or not a VC has been successfully retrievedfrom the VCA:

[0435] If a VC has been successfully retrieved from the VCA:

[0436] (1005) answers the received request for VC, with a positiveresponse comprising the VC which has been retrieved. Optionally, the VCis validated before being sent back in the response. The VCP then waitsfor the next request for VC.

[0437] If a VC has not been successfully retrieved from the VCA:

[0438] (1006) tests whether or not the VCA requires the received file tobuild the VC. This test uses information retrieved from the messagewhich has been received from the VCA in response to the short requestsent in (1003). Said information indicates whether or not the VCArequires the file to build the VC.

[0439] If the VCA requires the file to build the VC:

[0440] (1007) retrieves a VC associated with the received file from theVCA identified by VCA_S_Id, using a full request. The VCP sends a fullrequest to the VCA identified by VCA_S_Id, in order to retrieve a VCassociated with the received file. This full request comprises thereceived file.

[0441] (1008) tests whether or not a VC has been successfully retrievedfrom the VCA:

[0442] If a VC has been successfully retrieved from the VCA

[0443] (1005) answers the received request for VC, with a positiveresponse comprising the VC which has been retrieved. Optionally, the VCis validated before it is sent back in the response. The VCP then waitsfor the next request for VC.

[0444] If a VC has not been successfully retrieved from the VCA:

[0445] (1009) tests whether or not the VCA is a Default VCA, and whenthe VCA is a Default VCA, whether or not another Default VCA isavailable. This test preferably uses an indication which is stored bythe VCP when it identifies the VCA, and which is determined using theVCP Table (1020).

[0446] If the VCA is a Default VCA, and no other Default VCA isavailable:

[0447] (1010) stores an information indicating that the VCP has not beenable to retrieve a VC associated with the particular file comprisedwithin the received request for VC. Possibly, a notification is alsosent to a Network Administrator.

[0448] (1011) answers the received request for VC, with a negativeresponse which indicates that no VC has been retrieved. The VCP thenwaits for the next request for VC.

[0449] If the VCA is not a Default VCA, or if the VCA is a Default VCAbut another Default VCA is available:

[0450] (1012) excluded the VCA identified by VCA_S_Id, from the list ofVCAs which can possibly be used to retrieve a VC for the receivedrequest. Goes back to the identification of a VCA, in step (1002), sinceanother VCA (typically a Default VCA) may be able to build the VC.

[0451] If the VCA does not require the file to build the VC: The VCA istherefore not able to build the VC.

[0452] Continues in step (1009) to test if the VCA is a Default VCA.

[0453] If VCA_S_Id is not retrieved from information comprised withinthe received request:

[0454] (1013) tests whether or not the identifier of a VC Relay (VCR) iscomprised within the received request for VC. Said identifier is thenreferred to as “VCR_S_ID”. Typically, said VCR identifier may beimbedded within the received file (for instance in the “organization”section), or possibly derived from any information retrieved from thereceived request.

[0455] If VCA_S_Id is retrieved from information comprised within thereceived request:

[0456] (1014) retrieves the identifier (VCA_S_Id) of a VCA which hasauthority to build a VC for the received file, from the VCR identifiedby VCR_S_Id. The VCP sends a short request to the VCR identified byVCR_S_S_ID, in order to retrieve the identifier (VCA_S_ID) of a VCAwhich has authority to build a VC for the received file. Typically, saidshort request comprises the following information:

[0457] The file name, and file type of the received file.

[0458] The size of the received file,

[0459] The CRC of the received file. Typically, the file CRC iscalculated using the received file.

[0460] The list of anti-virus programs and levels that must be used bythe VCA to build the VC. Possibly, said list is empty, which means thatany anti-virus program and level can be used. Typically, said list isthe list which was received in the request (“RCV_AV_Checker_List”).Possibly, said list can also be a combination of “RCV_AV_Checker List”and some configuration information of the VCP (for instance a NetworkAdministrator may want to enforce a specific and updated list ofanti-virus programs and levels that must be used to build the VC).Typically, the VCR_S_Id comprises the address (for instance the IPaddress) of the VCR.

[0461] (1015) tests whether or not the identifier (VCA_S_Id) of a VCAhas been retrieved from the VCR.

[0462] If the identifier (VCA_S_Id) of a VCA has been retrieved from theVCR:

[0463] Continues in step (1003) in order to retrieve a VC for thereceived file, from said identified VCA.

[0464] If the identifier (VCA_S_Id) of a VCA has not been retrieved fromthe VCR:

[0465] (1016) retrieves the identifier (VCA_S_Id) of a Default VCA, fromthe VCP Table (1020).

[0466] Continues in step (1003) in order to retrieve a VC for thereceived file, from said identified VCA.

[0467] If VCR_S_Id cannot be retrieved from information comprised withinthe received request:

[0468] (1017) retrieves one record (called “Record_S”) from the VC ProxyTable. Said record is preferably identified by:

[0469] Its “File_Provider” field, which must be equal to (or mustcomprise) either:

[0470] the “RCV_issuer” which has been received in the request for VC,or

[0471] the file provider identifier which is possibly imbedded in thefile. Possibly, said record can also be identified by:

[0472] Its “File_Identity” field, which must be equal (or must comprise)the file identifier retrieved from the file.

[0473] Optionally, its “File_Name”, “File_Type”, “File Size” and“File_CRC” which must be equal to respectively) the name, type, size,and CRC of received file. At least a Default record can be identified.

[0474] (1018) tests whether or not the identifier of a VCA that can beretrieved from the VCP Table. A VCA section is primarily selected within“Record_S”. Preferably, the selected VCA section is a section which“AV_Checker_List” is equal to (or comprises) “RCV_AV_Checker List”. Theidentifier of a VCA can be retrieved from the VCP Table, when saidselected VCA section comprises a VCA Identifier in its “VCA Id” field.

[0475] If the identifier (called VCA_S_Id) of a VCA can be retrievedfrom the VCP Table:

[0476] Continues in step (1003) in order to retrieve a VC for thereceived file, from said identified VCA.

[0477] If the identifier of a VCA cannot not be retrieved from the VCPTable:

[0478] (1019) tests whether or not the identifier of a VCR that can beretrieved from the VCP Table. A VCA section is primarily selected within“Record_S”. Preferably, the selected VCA section is a section which“AV_Checker_List” is equal to (or contains) “RCV_AV Checker_List”. Theidentifier of a VCR can be retrieved from the VCP Table, when saidselected VCA section comprises a VCR Identifier in its “VCR_Id” field.

[0479] If the identifier (called VCR_S_Id) of a VCR can be retrievedfrom the VCP Table:

[0480] Continues in step (1014) in order to retrieve, from the VCRidentified by VCR_S_Id, the identifier of a VCA which has authority tobuild a VC for the received file.

[0481] If the identifier of a VCR cannot be retrieved form the VCPTable:

[0482] Continues in step (1016) in order to retrieve the identifier(VCA_S_Id) of a Default VCA, from the VCP Table (1020).

[0483] Advantages of the present invention include retrieving anexisting Virus-free Certificate from a cache. This is a very efficientoperation in term of time and performance, compared with generating anew virus-free Certificate; Also, a virus-free Cache (VCC) providessystems with existing virus-free Certificates (VCs which are alreadybuilt), and therefore off-loads Virus-free Certificate Authorities(VCAs). The overall performance of Virus-free Certificate Authorities(VCAs) is improved because VCAs have less virus-free Certificates togenerate. Further, multiple and distributed Virus-free CertificateCaches (VCCs) are usually attached to the LAN/WAN network. They arepreferably placed close to systems requiring virus-free Certificates(VCs). Because a VCC is generally closer than a VCA, the response timefor retrieving a virus-free Certificate from a VCC is therefore improvedcompared with the response time which is necessary to retrieve avirus-free Certificate from a VCA.

[0484] Still further, the traffic, across the LAN/WAN network, generatedby the virus-free Certificate requests is reduced. Less requests forvirus-free certificates are sent to the Virus-free CertificateAuthorities (VCAs).

[0485] While the invention has been particularly shown and describedwith respect to preferred embodiments thereof, it will be understood bythose skilled in the art that the foregoing and other changes in formand details may be made therein without departing form the spirit andscope of the invention.

Having thus described our invention, what we claim as new, and desire tosecure by Letters Patent is:
 1. A method, for use in a virus-freecertificate cache, of caching one or multiple virus-free certificates,each virus-free certificate certifying that a file is virus-free, saidmethod comprising the steps of: receiving a virus-free certificaterequest for a file; identifying the file in a cache table, said cachetable comprising for each identified file one or a plurality ofvirus-free certificates; selecting in the cache table one virus-freecertificate for the identified file, using one or a plurality ofanti-virus criteria; retrieving from the cache table said selectedvirus-free certificate; sending back in response to the virus-freecertificate request the retrieved virus-free certificate.
 2. The methodaccording to claim 1 wherein the virus-free certificate requestcomprises: a list of one or a plurality of anti-virus programs toexecute on the file to determine whether the file is virus-free or not.3. The method according to claim 1 wherein the virus-free certificaterequest further comprises: an identification of the file.
 4. The methodaccording to the claim 1 wherein the virus-free certificate requestfurther comprises: an identification of a virus-free certificateauthority, said virus-free certificate authority having authority togenerate virus-free certificates.
 5. The method according to claim 1wherein the virus-free certificate comprises: the list of the one orplurality of anti-virus programs that have been executed on the file. 6.The method according to claim 1 wherein the virus-free certificatefurther comprises: a virus-free certificate authority identification. 7.The method according to claim 1 wherein the step of selecting in thecache table one virus-free certificate for the identified file using oneor a plurality of anti-virus criteria comprises the further steps of:comparing the list of one or a plurality of anti-virus programscomprised in each virus-free certificate associated with the identifiedfile in the cache table with the list of one of a plurality ofanti-virus programs comprised in the received virus-free/certificaterequest; and where the list of one of a plurality of anti-virus programscomprised in a virus-free certificate associated with the identifiedfile includes the list of one or a p lurality of anti-virus programscomprised in the received virus-free certificate request: selecting saidvirus-free certificate.
 8. The method according to claim 1 wherein thestep of selecting in the cache table one virus-free certificate for theidentified file using one or a plurality anti-virus criteria comprisesthe further steps of: comparing the virus-free certificate authorityidentification comprised in each virus-free certificate associated withthe identified file in the cache table, and the virus-free certificateauthority identification comprised in the received virus-freecertificate request: and where the virus-free certificate authorityidentification comprised in a virus-free certificate associated with theidentified file is identical to the virus-free certificate authorityidentification comprised in the received virus-free certificate request:selecting said virus-free certificate.
 9. The method according to claim1 wherein the step of identifying the file in a cache table comprisesthe further steps of: If the file is not identified in said cache table:forwarding the received virus-free certificate request to anothervirus-free certificate cache; receiving a virus-free certificate inresponse to said forwarded virus-free certificate request; sending backin response to the received virus-free certificate request, saidreceived virus-free certificate.
 10. The method according to claim 1comprising the further step of: receiving a request to update the cachetable, said request comprising a virus-free certificate; storing saidvirus-free certificate in the cache table.
 11. The method according toclaim 10 wherein the step of receiving a request to update the cachetable comprises the further step of: forwarding said request to anothervirus-free certificate cache.
 12. The method according to claim 1comprising the further step of: discarding from the cache table thevirus-free certificate which are no more valid.
 13. The method accordingto claim 1 comprising the further steps of: selecting in the cache tableone or a plurality of virus-free certificates, using an informationindicating for each virus-free certificate the date of the latestvirus-free certificate request which has been received for saidvirus-free certificate; discarding from the cache table said one orplurality of selected virus-free certificate.
 14. The method accordingto claim 1 comprising the further steps of: selecting in the cache tableone or a plurality of virus-free certificate, using an informationindicating for each virus-free certificate the number of virus-freecertificate request which have been received for said virus-freecertificate; discarding from the cache table said one or a plurality ofselected virus-free certificate Comprises.
 15. The method according toclaim 1 wherein the generated virus-free certificate comprises: a filesignature for certifying that the file is declared a virus-free by theselected virus-free certificate authority.
 16. The method according toclaim 1 wherein the virus-free-certificate further comprises: a fileidentification; a public key for decrypting the file signature; acertificate signature for authenticating the virus-free certificate; anindication of the virus-free certificate validity.
 17. A system forcaching one or more virus-free certificates within a LAN/WAN network,each virus-free certificate certifying that a file to be downloaded to aclient is virus-free, said system comprising: a mechanism for receivinga request for a virus-free certificate associated with a file to bedownloaded to said client; cache table device for storing one or morevirus-free certificates for files, said cache table device includinglook-up mechanism for identifying one or more virus-free certificatesassociated with a requested file in a cache table; said look-upmechanism enabling selection of one virus-free certificate for theidentified file using one or a plurality of anti-virus criteria; and,mechanism for retrieving from a cache table said selected virus-freecertificate; and, in response to said request, returning a retrievedvirus-free certificate with said file.
 18. A program storage devicereadable by a machine, tangibly embodying a program of instructionsexecutable by the machine to perform method steps for caching one ormore virus-free certificates within a LAN/WAN network, each virus-freecertificate certifying that a file to be downloaded to a client isvirus-free, said method steps comprising: a) receiving a virus-freecertificate request for a file; b) identifying the file in a cachetable, said cache table comprising for each identified file one orplurality of virus-free certificates; c) selecting in the cache tableone virus-free certificate for the identified file using one or aplurality of anti virus criteria; and, d) retrieving from the cachetable said selected virus-free certificate and returning a retrievedvirus-free certificate with said file.